In recent years, the area of mobile computing in wireless networks has seen explosive growth both in terms of the number of services provided and the types of technologies that have become available, as evidenced by cellular phones, PDA's, Wi-Fi, Grid and RFID technologies. Distributed software systems for mobile computing are employed to communicate over a wide range of communication networks, including the Internet. One example of a distributed software system used or proposed for formal specification of business processes and interaction protocols is Business Process Execution Language for Web Services (BPEL). BPEL defines an interoperable integration model that facilitates expansion of automated process integration in both intra- and inter-corporate environments.
In addition to one key feature of functionality for business and other distributed software systems, another key feature for maintaining distributed systems is survivability. Survivability is defined as the capability of a service to fulfill its missions in a timely manner, even in the presence of attacks, accidents, or failures due to constant topological changes and unreliable communication channels. For simplicity, attacks, accidents, and/or failures are combined herein under the term “attack”. There are three key survivability properties: resistance, recognition, and recovery. Recovery is the capability to maintain critical components and resources during attack, limit the extent of damage, and restore full services following attack.
Because of the severe consequences of failure, organizations are focusing on service survivability as a key risk management strategy for business processes. One approach to meet this challenge is to consider a system at the overlay network level to be a composition of services. Each service makes its functionality available through well-defined or standardized interfaces. This approach yields a Service-Oriented Architecture (SOA) in which services are fundamental elements that can be independently developed and evolved over time. An SOA consists of services, their compositions, and interactions. Each service is a self-describing, composable, and open software component. SOAs typically involve layers of services each with a defined goal and functionalities. For wireless activities as an example, the wireless environment reacts rapidly to services attacks, therefore both recovery and adaptive mechanisms are required to maintain survivability. Using business processes as an example, known business process descriptions require the specification of both the normal workflow and the possible variations in workflow due to “exception” situations that can be anticipated and monitored. Normal workflow variations can be anticipated and dealt with at the process level. An exception is a special event that deviates from normal behavior or prevents normal process execution. Exception situations are generally unanticipated or attack situations which require a more adaptable approach for survivability.
Workflow management is the specification, decomposition, execution, coordination and monitoring of workflows. A workflow management system (WFMS) is the middle-ware to support workflow management. Workflow management is generally provided in a software system designed to support interoperable application-to-application interaction over a network. When the network is distributed over one or more Web services, however, problems can occur when the topology of one or more network nodes change, for example when communication between a fixed or ground based station is interrupted as a mobile platform such as an aircraft changes position relative to the ground based station. Exceptions occurring in workflows associated with Web services as a result of a system attack currently involve human intervention to resolve and are identified as “exception handling” techniques.
Exception handling techniques are known which deal with the recovery aspects of survivability, but which are not pre-emptive or capable of adaptably reacting to exception situations in terms of workflows. For example, Hwang et al. in the article “Mining exception instances to facilitate workflow exception handling”, published in Proceedings of the 6th International Conference on Database Systems for Advanced Applications, pp 45-52, 1999, provide a rule base that consists of a set of rules for handling exceptions. If none of the rules match the current exception, a search on the previous experience in handling similar exceptions is conducted. Algorithms are also described to identify the exception records by classifying the kind of information about exceptions, defining the degree of similarity between two exceptions, and searching similar exceptions. An improved approach to handling exception situations occurring due to workflow attack(s) is therefore required. Similarly, F. Casati and G. Pozzi in their article “Modeling Exceptional Behaviors in Workflow Management Systems”, published in Proceedings of International Conference on Cooperative Information Systems (CooplS'99), 1999, present a methodology for modeling exceptions by means of activity graphs. The taxonomy of expected exceptions are described by categorizing and mapping them into activity graphs. Also shown is how to handle the exceptions in each class. Further provided are methodological guidelines to support exception analysis and design activities. None of these works, however, provide a formal approach to describe exception flows in terms of workflow in mobile environments, and none provide a standardized language for capturing the knowledge of exception handling or a standardized framework to support exception handling in a distributed environment.